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User Interface 
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Memory: 

> Operating System 

> Windowing Environment 

> File System m 

> Application Software 

> Browser f mi 

> Energy Model Creator — 

> Device Drivers 32 

> Battery Monitor 

> -« ,,420 

> Means enabling energy- 
aware software control 



Display 



Display Panel 



Controller 



Drivers 



kite 



Image Processor 
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profiling P arameters: 



Operating power 
Battery Capacity (current state) 
Power savings 
Cost 

User-specified Hints (user-interface) 

Application-generated Hints 

(indications) 

Operating scenario 

Image Repertoire 

Screen Characteristics 

- Resolution, Brightness, Contrast 

- Array Size 

- Refresh Rate 

- Color and Gray-Scale Variations 
Ambient light 

Processing Requirements 
Memory Capacity 

Functionality Supported by the Display 
(display technology; display drivers) 
Number of Displays (and, IF >1, How 
Data is Partitioned among Displays) 
Acceptable Thresholds 
Acceptable Duration of Reduced 
Functionality Levels 
Transition Overhead 
Transition Hysteresis 



/ 



Dis play Parameters: 
Intensity 
brightness 
Color 

Refresh Rate 
Gray-Scale 
Ambient illumination 
Contrast 
Array Size 
Number of Tiles 



Energ y Model .(Static/Dynamic): 
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Average screen area used by 
contents in the area of interest 
(e.g., a frame or window of 
focus) 

Average screen area used by 
contents of peripheral interest 
(e.g., other windows) 
Suggested values for display 
parameters (functionality level) 
per pixel or group of pixels 
(resolution, refresh rate, color, 
brightness...) 

Suggested screen areas not 
requiring full functionality level 
and suggested durations 
Power consumption 
characteristics (power as a 
function of number of pixels 
turned on, and/or power as a 
function of display parameter 
values) 
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identity level ot 
software at which 
pixels are to be 
controlled 



son 




create a pixel energy model , 
(static or run-time energy 
profiling) 
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identify pixels marked for 
being controlled, and for 
each such pixel begin: 



i 
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use the pixel energy model 
and parameters to determine 
whether there are any pixels 
to be controlled 
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identify each pixel functionality 
(display parameter) to be 
controlled, and for each 
parameter begin: 
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identify hardware involved in 

pixel functionality-level 
(display parameters) control 



identify threshold values and 
round-off levels 
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identify any constraints that 
may prevent the system from 
controlling the pixels 
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send signals to device drivers 
that control the display, 
unless constraints 



( end ) 
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for each pixel on the screen 
begin: 
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measure level of functionality 
used by measuring values of ' 
display parameters 



compare the measured values of 
display parameters with their ^ 
respective full values 



mark the pixel as a candidate for 
being controlled if less than the full 
level of functionality is being used 



last pixel on the display? 




Fig. (ok 



for each pixel on the display 
begin: 



determine if full functionality level is 
required (measured by required ' 
values of display parameters) 



detect hints regarding level of 
functionality (e.g., OK to brighten 
only window of focus and dim 
background) 
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compare the required values of 
display parameters with their 
respective full values 



mark the pixel as a candidate for , 
being controlled if the full level of 
functionality is not required 




Fig. GB 



